A couple of nits and FYIs:

• I believe this target name can be generalized to acquire-logger. It doesn't need to be Zarr-specific.
• Directly using the target name instead of a variable improves readability, maintainability, and the overall robustness of your CMake configuration. The indirection of a variable is unnecessary in most use cases and can introduce subtle bugs or confusion if you have multiple targets. Most of the time people use it to reduce redundancy, but it's typically unnecessary.

The fact that these types are not defined within the logger target compromises encapsulation. If the logger is defined as a standalone target, it should be self-contained and reusable. Could we create an additional header file, perhaps named logger_types.h, with a C interface to address this issue?

If this is only used once, we could inline this variable.

This relates to the filtering issue discussed in the previous PR. My preferred API would allow users to enable or disable logs while handling filtering themselves. I find the current pattern suboptimal because it assumes users know our predefined log levels and lacks flexibility. For instance, a user might want to see info logs but not debug logs.

I mentioned this in the comprehensive PR review, but a modern approach to handling an arbitrary number of arguments is using variadic templates.

Why would a warning message go to std::cerr?

Add default case for completeness. Are we using a code linter like clangd/clang-tidy or sonar? This issue should be flagged by such tools.

I think I mentioned this in the large PR review. I would extract this code and std::put_time to a separate function. This snippet is copied from a logger that I wrote a while back so it may need to be adjusted a bit if you decide to use it.

auto GetTimestamp() -> std::string {
    using std::chrono::system_clock;
    auto now = system_clock::now();
    auto in_time_t = system_clock::to_time_t(now);

    auto time_info = std::tm{};
    #ifdef _WIN32
        localtime_s(&time_info, &in_time_t);
    #else
        localtime_r(&in_time_t, &time_info);
    #endif

    return fmt::format("{:04}-{:02}-{:02} {:02}:{:02}:{:02}",
                       time_info.tm_year + 1900,
                       time_info.tm_mon + 1,
                       time_info.tm_mday,
                       time_info.tm_hour,
                       time_info.tm_min,
                       time_info.tm_sec);
}

I think that std::localtime is not thread-safe. See my previous code snippet that uses localtime_s or localtime_r.